Tal como se puede observar en los gráficos, realizamos 3 mediciones en días y horarios distintos para
poder analizar y comparar las diferentes aproximaciones.
En todos los casos se realizaron mediciones sobre la totalidad de la lista de las universidades.

Lo primero que notamos fue que hubo 5 universidades que no respondían los mensajes de \texttt{echo-request}.
Esto fue tanto en las mediciones con nuestra implementación como también con la aplicación \texttt{ping}
nativa de Linux. Probablemente esos hosts tengan deshabilitado la opción de responder este tipo de
mensajes ICMP como medida de protección ante un posible ataque de denegación de servicio.

En las gráficas se puede observar de forma comparativa los tiempos de nuestro ping y el de linux.
Se observa que en casi la totalidad de los casos el tiempo del ping de linux es un poco menor.
En un comienzo creímos que esto se debía a optimizaciones de linux, como por ejemplo que pudiese llegar
a mandar varios paquetes de forma conjunta (aunque las mediciones fueses individuales) de manera de lograr
menores tiempos de respuesta totales. Pero cuando analizamos con Wireshark ambas ejecuciones
notamos que se obtenían tiempos muy similares entre el ping request y ping response de cada método. 
Con lo cual concluímos que las diferencias en los tiempos están dadas por la interpretación 
del código python de las funciones de scapy sumadas al sistema de medición utilizado.

También se puede observar el tiempo de RTT teórico de la velocidad de fibra óptica
utilizando distancias rectilíneas entre en origen (Bs. As.) y las ciudades propias de cada host
de destino. El valor usado como velocidad de fibra fue de $2 * 10^5$ km/s.
Se observa que los tiempos teóricos de fibra están muy por debajo de los tiempos de nuestra implementación
y de la nativa de linux. Esto se debe al hecho de que dos host no se comunican de forma
directa sino que existen varios host intermedios por los cuales pasan los paquetes, 
y la longitud del camino es mucho mayor a la distancia rectilinea calculada. 
Además influyen otros factores de red, como la congestión, las velocidades y el procesamiento
de colas de los hosts intermedios, los diversos caminos que pueden tomar los paquetes 
y también el hecho de que la conexión real no tiene la velocidad teórica de fibra.
En la parte de análisis de traceroute se analiza mejor la influencia de los 
distintos caminos que pueden tomar los paquetes.

Otro factor importante es el día y la hora en la que se accede al host. 
En los experimentos realizados uno de los hosts que mas diferencia mostró fue 
el de la \textbf{Pontificia Universidad Católica de Chile} \texttt{(www.uc.cl)},
con los siguientes tiempos:

\begin{description}
  \item[Domingo 20hs] 356ms
  \item[Lunes 14hs] 460ms
  \item[Martes 09hs] 795ms
\end{description}

Se puede observar que el tiempo de respuesta del día domingo es más del doble 
que el tiempo de respuesta del martes. Esto es esperable ya que al ser un sitio 
web de una universidad se espera que haya mas gente que entren al host durante 
la semana y no tanto durante el fin de semana, lo cual influye en la carga del host 
y su tiempo de respuesta. Si bien este factor no tiene nada que ver con la velocidad de la red, 
influye en que tan rápido podemos obtenee un \texttt{ICMP-REPLY} del otro host.
